home *** CD-ROM | disk | FTP | other *** search
/ USA Bestseller / USA BESTSELLER Vol 1-95 (Hepp-Computer)(1995).iso / e190 / vbench.txt < prev    next >
Text File  |  1995-02-20  |  10KB  |  265 lines
  1.  
  2. --------------------------------- VBENCH -----------------------------------
  3.  
  4. Requirements:
  5. ------------
  6.  
  7. *  80286 or higher processor
  8. *  DOS 2.0 or higher
  9. *  VGA compatible graphics card
  10.  
  11. To compile you need:
  12.  
  13. *  C++ compiler -> BORLAND C++ 3.1
  14. *  Assembler    -> TASM 3.1+
  15. *  Linker
  16. *  Mark Betz's HTimer class
  17.    Where to get: Compuserve-> the Gamer's forum, Game Design library
  18.  
  19. Files Included:
  20. --------------
  21.  
  22. In addition to this file, the following files should also be in the
  23. ZIP file:
  24.  
  25. *  VBENCH.EXE  - The executable video benchmark program
  26.  
  27. *  VBENCH.CPP  - The main C++ source module, takes care of
  28.               calling and calculating time for the benchmarks.
  29.  
  30. *  BENCH.ASM   - The benchmark Assembly language source module,
  31.               includes all benchmark code.
  32.  
  33. *  VIDEO.ASM   - The video mode setup and buffer management code.
  34.  
  35. *  VBENCH.MAK  - The make file used to compile program
  36.  
  37. *  VBENCH.PRJ  - The Borland C++ 3.1 project file used to compile program
  38.  
  39. Description:
  40. -----------
  41.  
  42.     The VBENCH program was developed for the prime purpose of comparing
  43. different blit (block-transfer) techniques in both mode 13h and tweaked
  44. mode (planar mode 13h with 4 pages). Hopefully, the benchmarks will
  45. serve the purpose of helping graphics programmers choose the technique
  46. that suits their application best, based on some of the timing results.
  47. By no means should these results be used as the _sole_ reason for
  48. choosing a technique, because there are many special cases that aren't
  49. accounted for in the benchmarks.
  50.  
  51. Usage:
  52. -----
  53.  
  54.     To use the benchmark program, all that's required is that you type 
  55. in it's name at the command line, like so:
  56.     VBENCH
  57.  
  58.     Press a key at the prompt, and the tests will then go underway...
  59. depending on your system, and on the amount of tests being done, this
  60. may take some time. Once they are finished, the program will exit and
  61. display the benchmark results on your screen.
  62.  
  63.  
  64. Benchmark Info:
  65. ---------------
  66.  
  67. -    For Ram-to-Video, AND for Video-to-Ram benchmarks, a 64,016 byte
  68. buffer was used as the Ram buffer, and therefore named ram_buffer. The
  69. extra 16 bytes on the end are for special non-aligned accesses. For
  70. Video-to-Video benchmarks, I copied from higher addresses to lower
  71. addresses, using an incrementing index. (ex: 1st copy moves from byte
  72. 4 to byte 2, 2nd copy moved from byte 5 to byte 3,etc). The reason for
  73. me doing this was because this seemed to be the only way to get the
  74. average speed of moves. It may sound weird, but in my tests, at least,
  75. on my system, I got much faster speeds if I copied _ahead_, by, say,
  76. about 2 bytes, as compared to copying ahead by 32 bytes or copying
  77. 'backwards'. I'd be interested in hearing if the same situation occurs
  78. to others out there.. all you need do is change the video transfer
  79. functions in BENCH.ASM, and compare those results to the 'backwards'
  80. moves.
  81.  
  82. -    As of yet, all benchmarks are 64,000 byte moves, repeated 10
  83. times. The functions are not _called_ 10 times, but the functions
  84. are _performed_ 10 times. Perhaps in the future I will change this,
  85. but it doesn't make a difference right now, since I am timing video
  86. speed, not function speed.
  87.     No parameters were passed to the benchmark functions, and no
  88. variables were accessed by the function. Each function was aligned
  89. on a paragraph boundary. The program was compiled in COMPACT model,
  90. so all CALLs were NEAR calls.
  91.  
  92. -    One thing to note.. all current functions are aligned optimally
  93. for the type of move being done,assuming the type is of word or dword.
  94. The reason for this is that aligned moves work much faster than unaligned
  95. moves, and you should try to avoid those types of moves as best you can.
  96. On my system, I have found that unaligned moves can be just as slow, or
  97. even slower than BYTE moves.
  98.  
  99. -    For mode 13h benchmarks, ram_buffer was treated as a 64,000 pixel
  100. buffer setup just like the screen (linear bitmap).
  101.  
  102. -    For Tweaked mode benchmarks, ram_buffer was treated as though it
  103. was set up in a planar fashion, meaning every 16,000 bytes of the buffer
  104. represented a different plane. This isn't a cheat, but an ideal setup
  105. for Tweaked mode video transfers.
  106.  
  107. -    I didn't do a interleaved write measure because I usually always
  108. code my loops to use REP MOVS' instructions. The interleaved write
  109. requires that you do a LOOP, which will always be slower than a REP
  110. instruction, since REP doesn't need to load the instruction pointer
  111. and whatnot. If you wanted to do a fair comparison of interleaved and
  112. non-interleaved writes, you would want to make them _BOTH_ contain LOOP
  113. instructions, avoiding the REP MOVS instructions where possible.
  114.  
  115. Specific Benchmark Info:
  116.  
  117. * Shared Benchmarks (benchmarks done in both mode 13h and Tweaked mode)
  118.  
  119.     - Byte Blit
  120.  
  121.       Write to the screen, using BYTE moves.
  122.  
  123.     - Word Blit
  124.  
  125.       Write to the screen, using WORD moves.
  126.  
  127.     - Word Read
  128.  
  129.       Read from the screen, using WORD moves.
  130.  
  131. * Mode 13h-specific Benchmarks
  132.  
  133.     - Word Video Transfer
  134.  
  135.       Video Transfer (moving data using the video card as the source
  136.       and the destination), using WORD moves.
  137.  
  138. * Tweaked mode-specific Benchmarks
  139.  
  140.     - Hardware Video Transfer
  141.  
  142.       Video Transfer (moving data using the video card as the source
  143.       and the destination), with the video card in Write Mode 1,
  144.       using BYTE moves. Write mode 1 gives a hardware-assisted
  145.       move which allows 32-bits to be moved with one MOVSB instruction.
  146.       32-bits equals 4 pixels in tweaked mode.
  147.  
  148. Adding Benchmarks:
  149. -----------------
  150.  
  151.     To add a benchmark is basically straightforward. The main module,
  152. VBENCH.CPP includes a file called VBENCH.H.. this file serves the
  153. purpose of defining the benchmarks to be done by the main program.
  154. There are two class definitions in VBENCH.H.. one named SharedBenchData,
  155. the other named BenchData. Each of these holds a description of the
  156. benchmark in string form, and a pointer or pointers to the benchmark
  157. function(s). The only thing these classes lack is the timing results
  158. (which are stored elsewhere in the program) for each test, but the
  159. reason for this is to make adding more benchmarks less work.
  160.  
  161.     Now, to add a benchmark test to the list, all you need to do is:
  162.  
  163.     1) Define the function prototype. There are 2 different 'slots'
  164.        for function prototypes, one for mode 13h function prototypes,
  165.        and one for tweaked mode function prototypes. While you don't
  166.        have to put the prototypes in these places, it does help in
  167.        readability and organization.
  168.  
  169.     2) Depending on the type of benchmark you are peforming, you either
  170.  
  171.         A) For mode-specific benchmarks, find the correct list, either
  172.            the Tweaked mode or Mode 13h list, and add another BenchData
  173.            object to the list. To add another BenchData object, you must
  174.            define it like such:
  175.  
  176.            function_address,bench_description
  177.  
  178.            The function_address is just the benchmark function name,
  179.            without the parentheses(). The bench_description is a
  180.            description of the benchmark being performed, in a string
  181.            form. Example:
  182.  
  183.            New13Blit,"A new blit function"
  184.  
  185.         B) For shared benchmarks (benchmarks that can be performed in
  186.            both mode 13h or Tweaked mode), find the shared_benchmark list,
  187.            and add another SharedBenchData object to the list. To add
  188.            another SharedBenchData object, you must define it like such:
  189.  
  190.            m13_function_address,tw_function_address,bench_description
  191.  
  192.            The m13_function address is just the mode 13h benchmark
  193.            function name, without the parentheses(), and the
  194.            tw_function_address is the Tweaked mode benchmark function
  195.            name. bench_description is a description of the benchmark
  196.            being performed. Example:
  197.  
  198.            NewBlit13,NewBlitTw,"A new blit function"
  199.  
  200.        Note: the bench_description strings are limited to 30 characters!
  201.  
  202.     3) Include the benchmark functions file in the compiling project,
  203.        and then compile away!
  204.  
  205.     Guidelines for creating benchmark functions:
  206.  
  207.     1) Right now I only do a loop of 10 64,000 byte moves. This can be
  208.        performed using byte,word, or dword transfers..just be sure to
  209.        indicate which kind was being done in the benchmark description.
  210.  
  211.     2) I align all benchmark functions on a paragraph boundary, to make
  212.        sure the timed function is at optimal speed. (though it might not
  213.        make _too_much_ difference in time)
  214.  
  215.     3) All system ram access is done on the ram_buffer which is located
  216.        in the Uninitialized Far Data segment, and also paragraph aligned.
  217.  
  218.     4) No parameters are passed, and no variables accessed from within
  219.        the functions.
  220.  
  221.     5) All functions requiring OUT's or somesuch activity do these within
  222.        the loop. Even if the OUT is needed only once, it still should
  223.        be included in the loop, to make sure no cheats are performed.
  224.        The loop I speak of is the outside loop, not the inner transfer
  225.        loops.
  226.  
  227.     You can use the current benchmark code as a reference if you like.
  228.  
  229. Notes:
  230. -----
  231.  
  232. * This program can be used and distributed without any worry. It is
  233.   asked, though, that it not be sold for profit. The benchmark can
  234.   be modified, but with these restrictions:
  235.  
  236.   1) Adding more benchmarks to the program is allowed, so long as
  237.      the current benchmarks remain in the program.
  238.  
  239.   2) Modifying the current benchmarks is allowed ONLY if you
  240.      contact the author of that benchmark. Right now, there's only
  241.      one programmer (me), but I hope that others will also contribute
  242.      to this benchmark program.
  243.  
  244.   3) Modifying the _way_ in which the benchmarks are timed is allowed
  245.      ONLY if you contact me first (Dan Corritore)
  246.  
  247. * Actually, I need to find some way of making sure version numbers
  248.   and additions to the benchmarks are handled correctly, so for now,
  249.   don't upload any additions/changes until speaking with me (Dan Corritore).
  250.  
  251. * Eventually I will rewrite this documentation once other benchmarks
  252.   are added, or perhaps if the benchmark program is changed in any way.
  253.   Any help or suggestions with documentation layout and stuff would be
  254.   greatly appreciated, as I'm not the best documentor.
  255.  
  256. * Please, if you see a problem with the program code, or any mistakes,
  257.   or perhaps think I'm going about doing the benchmarks totally wrong,
  258.   let me know!
  259.  
  260. Email address(es):
  261. -----------------
  262.  
  263.     Dan Corritore, author of VBENCH 1.0:
  264.         CompuServe address: 70243,1110
  265.